들어가며
첫 서비르 오픈 준비를 하고 부족한 부분을 보안 할 점, 문제 해결 상황, 경험 등을 기억하고 기록하여 다음에는 더 개선된 행동을 하기 위해 적어 놓는다.
부하테스트 통과 시키기
서비스를 오픈하기전에 부하테스트를 하여 서버에 어떤 영향이 있을지 모르니 사전에 알기 위함이고 앞으로 팀내 서비스를 출시 할 때 부하테스트 스템을 추가하여 표준적인 부하 임계치를 정하고자 시작하게 되었다.
응답시간 지연
Scouter에서 PHP에게 요청하는 응답시간이 지연되었다. 결과적으로 TPS는 15밖에 나오지 않았고 서비스 출시가 어려운 상황이었다.
원인은 PHP에게 요청하는 데이터 사이즈도 컸고 어떠한 로직에 의하여 Cache가 동작하지 않는 것이었다.
이부분은 Scouter를 보고 실장님에 인사이트로 원인을 알게 되었고 Scouter에서 나오는 데이터를 잘 분석하는 능력이 필요함을 느꼈다.
아무튼 서비스 출시를 위해서는 PHP에게 의존하는 것을 최대한 줄여한다. 그러기 위해 사용한 전략은 PHP에서 가져오는 html, 데이터를 Java로 내재화 하고 캐쉬를 적용하는 것이다.
캐쉬 적용
Spring Caffeine 캐쉬를 사용하였고 어쩔수 없이 PHP 콜이 필요한 부분은 캐쉬를 사용하였다.
캐쉬를 적용해 본것이 처음이었는데 캐쉬에 중요성과 캐쉬가 동작하는 개념을 알아야 할 필요성을 느꼈다.
작업이 끝나고 스트레스 서버에 반영 하였다.
EC2 t2.micro → t2.medium 교체
처음에 부하를 돌려도 Scouter에 반응이 없었는데 알고보니 토큰만료와 User-Agent 값이 달라서 로그인이 안되서 그런것이었다. 수정하고 테스트를 하였는데도 TPS가 50 밖에 되지 않는 것이었다.
실장님이 일단 공인망을 타는것을 내부망을 타도록 바꾸어 주셨고 서버 스펙도 t2.medium으로 교체하고 진행하였는데 TPS 320 !!! 통과다.
실장님이 말씀하시길 처음에 구동될때 Java가 초기화 될때는 CPU나 메모리 점유율이 크지만 곧 안정되서 떨어지는 곡선에 개형을 나타나지만 PHP는 떨어지지 않고 계속 유지되고 있다고 하였다. 요청은 PHP서버에서 받고 있긴 하지만 이대목에서 정확히 왜그런지는 모르곘다.
TODO 그라파냐 캡쳐사진 첨부
Visual GC 원격 접속
원격으로 부하테스트 서버에 접속하여 GC에 대한 모니터링을 할 수 있다.
그 과정에서 터미널로 포트를 확인하는 과정이 있었는데 이러한 부분은 내가 아예 몰라서 공부가 필요하다.
어? 배너가 안나오네??
다음날은 광복절 휴일이었다… 제발 오늘은 아무일 없기를… 칼퇴해야지!! 하는데 역시나 버그가 발생하였다.
퇴근 약 1시간 전 이었고 얼른 끝내야 겠다는 마음으로 버그 원인을 조사하기 시작하였다. 특정 쿠기가 있으면 일반 배너가 나와야 하고 특정 쿠기가 없으면 사이즈가 큰 확장 배너가 나와야 하는데 확장 배너에서 이미지가 안나오고 그냥 html이 텍스트로 나오는 것이다.
많은 삽질과 도움을 받아 버그는 해결 되었는데 해결 하는 과정 속에 문제 원인과 시간이 지체된 이유를 적어 본다.
PHP 코드를 잘 못 보고 있었다.
작업내용은 PHP 코드를 보고 JAVA 옮기는 것이었는데 a라는 파일 참고하여 개발하였는데 알고보니 수정된 a’ 파일이었던 것이다.
그래서 Java 코드를 다시 수정 하는것이 필요하였다. 하지만 빠르게 PHP코드를 이해하고 Java로 어떻게 구현할지 감이 잡히지 않았다. PHP에는 있어도 JAVA 영역에서는 굳이 필요없는 코드인데 그것도 옮기려는 뻘짓도 있었고 꼭 PHP코드를 그대로 복사하는 것이 아니라 이해하고 코딩을 했어야 했다. A->B->C 로 로직이 구현 되어 있어도 A->C 로 가는 좋은 방법이 있으면 그것을 구현하면 되는 것이다. 하지만 나는 PHP를 그대로 구현해야 탈이 없다는 것이 잠재되어 있었는지 PHP데로 하려고 이해하고 JAVA로 코드를 구현하려 보니 시간이 지체 되었다.
DB를 잘 못 보고 있었다.
구현하고 데이터를 확인하는데 디비랑 데이터가 다른것이다. 현상 특정 엔티티 프로퍼티에 값이 계속 null인 것이다. 많은 삽질 끝에 결국 DB주소를 잘 못 바라 보고 있었다…
하지만 그래도 원인은 그대로…
기존 PHP족 배너에서도 잘 나오던게 안나오고 있었고 이건 먼저 PHP쪽에 확인이 필요하였다. 결국 조치를 취하여 이제 배너는 나오게 된 상황이었다.
결국 개발자는 문제 해결 능력
배너는 나오고 있었지만 위에서 말했다 싶이 확장배너는 나오지 않았다. 특정 쿠키값을 지우면 나와야 하는데 안나오는 것이다. 옆에 선배 개발자님에게 도움을 받으며 문제를 하나하나 차근차근 까보기 시작했다. 지금 특정 쿠키를 지웠으니까 여기 조건으로 들어 왔을테고 근데 안나왔네? 그럼 PHP 소스를 보자아~~ 아 음… 아 여기 조건이 바뀌었네… 물론 이렇게 한방에 해서 해결 된건 아니었지만 문제 원인을 분석하기 위해 차근차근 하나씩 따져 보면서 접근하는 방식이 참 인상 깊었다. PHP랑 똑같이 했는데 안되면 그냥 스타일을 같이 먹여 보고 좀 이렇게 해보고 저렇게 해보고 그래서 결국 해내는 것 그 문제를 해결 하는 능력이 결국 개발자에 실력인것 같다.
그럼 나는 왜 스스로 문제를 해결하지 못했을까??
일단, 문제원인이 외부적인 문제도 있었다. 그럼 외부적이 문제가 무엇이었는지 파악을하고 질문을 하던지 공유를 하던지 해서 앞단에서 해결을 빨리 했어야 했는데 그러지 못헀다. 결국 이문제가 내부(나의 문제)인가 아님 외부 인가 부터 구별하는 혜안이 부족했던거 같다.
코드를 확실히 이해하지 않은 상태에서 코드 수정하기 바빴다.
코드를 이해하고 이것이 의미하는 바가 무엇인지 확실하게 이해해야 하고 코드를 수정해야 하는데 일단 수정하고 결과 보고 아니면 이렇게 수정하고 결과보고 계속 쳇바퀴만 돌고 문제는 해결되지 않고 시간은 지체 되어 결국 도움을 요청하게 되었다.
느낀점, 그래서 앞으로는?
적극적으로 이해하기 위해서 적극적으로 행동하자
물어보는게 제일 빠르다
다른 사람이 작성한 코드나 잘 모르는 업무라면 그 업무 담당자에게 확실하게 물어보자. 물어 볼때는 최대한 많이 정보를 얻기 위해서 무엇을 물어볼지 적어놓자. 그리고 이왕이면 내 자리로 데리고 와서 모니터 화면을 보면서 빠르게 이해시켜주면서 정보를 얻는것이 제일 좋다.
코드가 의미하는 바가 무엇인지 확실히 이해한다.
함부로 또는 건성으로 코드를 이해했다고 넘어가면 안된다.
정말 어떠한 문맥에서 이러한 코드를 작성했는지 무엇을 위해서 코드를 작성헀는지 확실히 이해하는 활동을 반드시 해야 한다.
개인공부는 업무를 하면서 잘 안된것들과 배운 경험들에 연장선에서 공부하자
결국 내가 지금 하고 있는 업무를 잘하면 된다. 그것들을 잘 습득해야 나중에 제대로 활용 할 수 있고 더 잘 할 수 있게 된다.
업무에서 잘 사용하지 않고 있는데 미리 공부한 지식들은 금방 까먹고 밑빠진 독에 물붓기가 되는 셈이다.
압박감 속에서 문제를 해결하는 능력이 진짜 능력이다.
사람들이 다 보고 있다. 나만 지켜 보고 있다. 부담감이 들고 내 행동 하나에 초점이 맞춰저 있어 되게 신경쓰인다.
하지만 일하면서 그러한 상황은 얼마든지 올 수 있다. 그러한 것들을 신경쓰지 않고 내 페이스를 유지하면서 정확하고 빠르게 생각하여 문제 원인을 찾고 해결하는 능력을 키우기 위해 의식적으로 노력해야 한다. 그럴려면 일할때나 개인 공부 할 때 시간을 재고 문제를 해결 한다는지 주위에 사람이 있다 항상 생각하고 문제를 푼다는지 하는 전략으로 해야 할 것 같다.
